Identify the Bug or Feature request

#3426

Description of the Change

Auras now calculate a separate area for each range, and associate those ranges with the corresponding colour in a DrawableLight. Previous behaviour was to render the full area of the aura repeatedly, once for each range.

Colourless ("bright") auras are not actually rendered, giving the effect of transparency. This matches the behaviour for lights and allows creating auras that start a certain range away from the token. Previous behaviour was to render such auras as white with a hardcoded alpha of 150. White auras can still be had by explicitly setting the colour to white, and this will also respect the users opacity preferences.

ZoneView.getLights(Type) has now been specialized to just handle auras, since that is all it was being used for anyways. Normal lights are handled a different way altogether.

Possible Drawbacks

Anyone using a purely colourless aura intending for a white value will now get nothing. Setting the aura colour to explicitly white will get a similar effect, though the opacity will respect the user's preferences unlike before.

The DrawableLights for auras are not cached in ZoneView, so there is the potential for some perf regression if other changes are made in the area. ZoneRenderer does cache the results and only calls it at most once per frame, so the current state of things will be fine.

Documentation Notes

Auras can have colours just like lights. Assigning different colours to different ranges will result in several colours being shown for the aura. E.g., if we have this aura:

Colourful Aura: aura circle 10 20#000000 30#555555 40#aaaaaa 50#ffffff

and attach it to a token, it will look like this:

Note that the innermost range does not have a colour, and so is presented as transparent.

Release Notes

• Auras render each of their colours only within the corresponding range. Colourless auras no longer render as white, but are transparent. Colour can be explicitly set to white if needed.

This change is